Methods and apparatus for a dual address space operating system

ABSTRACT

In one embodiment of the invention, a method is provided to allow an operating system to support both address space layouts of a SAS OS and a MAS OS at the same time, with the choice of which layout type to be used to be made by the application developer. In one embodiment the method includes: selecting one of a mostly private address space (MPAS) model and a mostly global address space (MGAS) model, where if the MPAS model is selected, then a process is permitted to map a shared object in a mostly private address space (MPAS) layout so that the process perceives a behavior as if the process is running on a multiple address space operating system, and where if the MGAS model is selected, then the process is permitted to map a shared object in a mostly global address space (MGAS) layout so that the process perceives a behavior as if the process is running on a single address space operating system.

TECHNICAL FIELD

Embodiments of the present invention relate generally to operatingsystems for computers.

BACKGROUND

An address space refers to a range of either physical or virtualaddresses that acre accessible to a processor or reserved for a process.A process is an instance of a program running in a computer. On acomputer, each process is allocated address space, which is some portionof the processor's address space.

Current and previous operating systems have only one address space modelthat is provided to the application developers. Current or previousoperating systems either have the “single address space model” or the“multiple address space model”. In the single address space model, anentire machine or computer has one address space that all applicationsuse. In the multiple address space model, each process running on thecomputer has its own address space. For the application writer, thesingle address space model has better performance, but less flexibility,than the multiple address space model.

Thus, the current approaches and/or technologies are limited toparticular capabilities and/or suffer from various constraints.

SUMMARY OF EMBODIMENTS OF THE INVENTION

In one embodiment of the invention, a method is provided to allow anoperating system to support both address space layouts of a singleaddress space operating system (SAS OS) and a multiple address spaceoperating system (MAS OS) at the same time, with the choice of whichlayout type to be used to be made by the application developer. Theapplication developer can choose the Mostly Private Address Space Model(MPAS Model) or the Mostly Global Address Space Model (MGAS Model).Therefore, the application developer will have the flexibility to choosewhich address space model to use on the same instance of the kernel.

In another embodiment of the invention, a method includes: selecting oneof a mostly private address space (MPAS) model and a mostly globaladdress space (MGAS) model, where if the MPAS model is selected, then aprocess is permitted to map a shared object in a mostly private addressspace (MPAS) layout so that the process perceives a behavior as if theprocess is running on a multiple address space operating system, andwhere if the MGAS model is selected, then the process is permitted tomap a shared object in a mostly global address space (MGAS) layout sothat the process perceives a behavior as if the process is running on asingle address space operating system.

These and other features of an embodiment of the present invention willbe readily apparent to persons of ordinary skill in the art upon readingthe entirety of this disclosure, which includes the accompanyingdrawings and claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a virtual address space architecture thatcan function with an embodiment of the invention.

FIG. 2 is a block diagram of a dual address space operating system, inaccordance with an embodiment of the invention.

FIG. 3 is a block diagram of a hashed page table, in accordance with anembodiment of the invention.

FIG. 4A is a block diagram of an address space layout for a 32 bit MPASapplication, in accordance with an embodiment of the invention.

FIG. 4B is a block diagram of an address space layout for a 32 bit MPASapplication (where the layout is shown as flat representation), inaccordance with an embodiment of the invention.

FIG. 5A is a block diagram of an address space layout for a 64 bit MPASapplication, in accordance with an embodiment of the invention.

FIG. 5B is a block diagram of an address space layout for a 64 bit MPASapplication (where the layout is shown as flat representation), inaccordance with an embodiment of the invention.

FIG. 6A is a block diagram of an address space layout for a 32 bit MGASapplication, in accordance with an embodiment of the invention.

FIG. 6B is a block diagram of an address space layout for a 32 bit MGASapplication (where the layout is shown as flat representation), inaccordance with an embodiment of the invention.

FIG. 7 is a block diagram of an address space layout for a 64 bit MGASapplication, in accordance with an embodiment of the invention.

FIG. 8 is a flowchart illustrating a method of allocating address spacefor 32 bit MPAS processes, in accordance with an embodiment of theinvention.

FIG. 9 is a flowchart illustrating a method of choosing the MGAS modelor the MPAS model.

FIG. 10 is a block diagram illustrating a method of identifying if anapplication will run under the MGAS model or MPAS model.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

In the description herein, numerous specific details are provided, suchas examples of components and/or methods, to provide a thoroughunderstanding of embodiments of the invention. One skilled in therelevant art will recognize, however, that an embodiment of theinvention can be practiced without one or more of the specific details,or with other apparatus, systems, methods, components, materials, parts,and/or the like. In other instances, well-known structures, materials,or operations are not shown or described in detail to avoid obscuringaspects of embodiments the invention.

An embodiment of the invention provides to the application user theflexibility to choose either a single address space (SAS) model ormultiple address space (MAS) model on the same instance of the kernel.The application user can choose between the two address space models,and the operating system will support both models.

The following terms are now defined, for purposes of providing abackground for understanding the various embodiments in accordance withthe invention.

-   Address space—An address space of a process refers to the range of    virtual addresses that are accessible by the process. A 32 bit    application will have a 32 bit address space and a 64 bit    application will have a 64 bit address space. An address space is    composed of a private address space and a shared address space.-   Aliasing—This occurs when two or more virtual addresses share (point    to) the same physical page. In computer systems that use virtual    memory, a page is a unit of data storage that is brought into real    storage (RAM) from auxiliary storage, also known as swap storage    (usually the hard disk) when a requested item of data is not already    in real storage (RAM).-   Equivalently Aliased—This is a condition when two virtual addresses    map to the same physical address, and where the two addresses map to    the same cache line in the processor's cache.-   Fault—This is condition that needs higher level software (virtual    memory) (VM) to resolve a memory reference exception. Faults are    generated when there is no translation in the page table or there is    an access violation.-   Mapping—This is range of virtual addresses that is associated with a    memory object (region). This is stored in a VM data structure called    “pregion” which contains a pointer to a memory object and the    address of a mapping to that memory object.-   Multiple address space operating system (MAS OS)—This is an    operating system that uses a unique address space for each process.    Sharing of the same object between two or more processes is achieved    by using aliasing to share memory. Thus, a process is prevented from    accessing an address that it has not mapped by not having a    translation.-   Mostly global address space (MGAS) process—Shared objects will    reside in the global address space. Shared objects will be placed in    the private address space when there is no space available in the    shared address space.-   Mostly private address space (MPAS) process—Both shared and private    objects will reside in the private address space by default. A user    could place the shared object in a global address space by using    special flag.-   Non-Equivalently Aliased—This is a condition in which two virtual    addresses map to the same physical address, but do not meet the    requirements for equivalently aliased addresses.-   Private Address Space—This is an address space that is available    only to a single process. In a current implementation (but not a    limitation in other embodiments), a private address space can    contain only private objects (with the exception of exclusive,    shared mappings).-   Private object—This is an object that is mapped only by one process    and is not shared with other processes. Examples of a private object    include, data, stack, and other types objects.-   Single Address Space operating system (SAS OS)—This is commonly    referred to an operating system that uses a global address space for    all processes. Sharing of the same object between two or more    processes is achieved by using the same global address. In a SAS OS    model, all processes share the same translation but use protection    keys to prevent a process from accessing an address that has not    mapped.-   Shared Address Space—This is an address space that is shared among    processes. In one embodiment, a shared address space can contain    only shared mappings.-   Shared Object—This is an object that can be mapped by one or more    processes. Examples of a shared object include, system Virtual    shared memory, file, and other types of shared objects.

An embodiment of the invention permits the applications user, instead ofthe OS designer, to decide whether the multiple address space operatingsystem (MAS OS) model or the single address space operating system (SASOS) model will be used for running applications that are run on acomputer. Through the application format, commands, and tools (such as,for example, a linker), the user can specify if the MAS OS model or SASOS model will run all applications. After the user specifies the addressspace model, the virtual memory will load an application, and based onthe address space model specified by the application, the text, data,and shared memory is accordingly assigned in memory.

FIG. 1 is a block diagram of a virtual address space architecture 100that can function with an embodiment of the invention. The virtualaddress space architecture 100 typically operates in a computer hardwareenvironment. Each process (e.g., Process A and Process B) contains a vasstructure (e.g., vas structures 102 a and 102 b). Each vas (virtualaddress space) structure has a linked list of user mappings. The usermappings are represented by the pregion structures (e.g., pregionstructures 103 a to 103 f). A pregion structure (generally referred toas pregion 103) contains a pointer to a memory object and an address ofthe mapping to that memory object. The memory object is represented bythe region structure 105. The region structure 105 stores a region table106 that maps the memory object to a physical address and backing store.The backing store could be one of anonymous, file or swap. Each entry inthe region table 106 contains a vfd 107 and dbd 108. The vfd 107contains the physical address in memory and the dbd 108 contains thelocation in the backing store.

The pregion structure 103 can be represented as a <vaddr, region offset>tuple and the region structure 105 can be represented as a <regionoffset, pfn> tuple. A translation is created by combining the two tuplesto form the <vaddr, pfn> tuple. As known to those skilled in the art, inprogramming languages, such as LISP, Python, Linda, and others, a“tuple” is an ordered set of values. The separator for each value isoften a comma (depending on the rules of the particular language).Common uses for the tuple as a data type are (1) for passing a string ofparameters from one program to another, and (2) representing a set ofvalue attributes in a relational database. In some languages, tuples canbe nested within other tuples within parentheses or brackets or otherdelimiters. Tuples can contain a mixture of other data types.

The virtual memory currently uses a non-aliased shared memory model toshare memory. All processes that map a shared memory segment (a memorymapped file or system virtual shared memory) will use the same globaladdress. In other words, the virtual address in the pregion 103 for allprocesses that share the same memory segment will be identical.

To support MPAS executables, an aliased shared memory model is typicallynecessary. All MPAS processes that map a shared memory segment will usea private address. In this case, the address in the pregion will bedifferent from other pregions.

An embodiment of the invention provides a flexible address space modelthe lets the application user to decide the address space model to besupported by an operating system. Reference is now made to FIG. 2. Theapplication developer can choose the Mostly Private Address Space Model(MPAS Model) 150 or the Mostly Global Address Space Model (MGAS Model)152. A processor (e.g., CPU) 159 will execute an operating system (OS)154 and other software in the computer 160. The operating system 154manages the applications that will run in the computer 160. Theoperating system 154 includes a kernel 162 which is the operatingsystem's inmost layer or core of services. Typically, the kernel 162includes a manager of the operating system's 154 address spaces inmemory or storage, so that the address spaces are shared among allcomponents and other users of the services of the kernel 162. Otherknown software and hardware components in the computer 160 are not shownin FIG. 2, for purposes of describing the functionality of embodimentsof the invention.

In the case where the MPAS model 150 is chosen by the applicationdeveloper, the application will have complete control of the addressspace process. The application will perceive the same behavior as thoughthe application was running on a traditional Multiple Address Spaceoperating system (MAS OS) (e.g., SUN or LINUX operating system). Exampleapplications are shown as the 32 bit application 155 and the 64 bitapplication 156. In this case, the application developer trades offperformance for more flexibility. A 64 bit application can, for example,choose a global address space for better performance by using specialflags such as MAP_GLOBAL when using the mmap( ) call and IPC_GLOBAL whenusing the shmat( ) call. This option (of choosing a global addressspace) is not available for 32 bit applications because of the limitedaddress space. The whole 4 GB addressable by a 32 bit application isdesignated as private due to limited address space.

In the case where the MGAS model 152 is chosen by the applicationdeveloper, the application does not have much control of the sharedaddress space of the process. The application will perceive the samebehavior as though the application was running on a traditional SingleAddress Space Operating System (SAS OS). Example applications are shownas the 32 bit application 157 and the 64 bit application 158. In theMGAS model 152, the application trades off flexibility for betterperformance. When an application (either a 32 bit and 64 bitapplication) wants to map a shared memory segment and the operatingsystem 154 has exhausted all of the shared address space, then theoperating system 154 may use a private address space of the process tomap the shared memory segment. This makes the address space model moreadaptive and avoids application failure. It reduces the address spacepressure but adds to the TLB pressure.

The dual address space OS 154 (FIG. 2) has the following benefits.

(1) It provides complete compatibility for existing applications.

(2) There is no performance degradation of existing applications orapplications that is compiled with default behavior.

(3) An application developer has the choice to decide betweenperformance and address space flexibility.

(4) It is extensible for future technical advances.

(5) With a multiple (dual) address space model, the system can runapplications that traditionally work well with a multiple address spaceOS and applications that work well with a single address space OS.

Discussed below are some terminologies relating to the dual addressspace model, in accordance with an embodiment of the invention.

The term “virtual address” means the 32 bit or 64 bit address (for a 32bit process or 64 bit process, respectively) that is generated withinthe context of or on behalf of a process. The entire range of virtualaddresses that can be generated constitutes the virtual address space(also referred herein as “address space”) of a process.

The term “global virtual address” is used to denote the combination ofaddress space identifier (ASID) and virtual address (or offset) that isused by the computer hardware to access a virtual memory location. Theaddress space is called “space ID” in the HP-PA architecture(Hewlett-Packard's range of RISC processors) and is called “region ID”in Intel's Itanium architecture. As an example, consider 32 bitprocesses. Each process has an address space that ranges from 0x00000000to 0xFFFFFFFF (see FIG. 4B, for example). However, the same virtualaddress within two (2) processes may map to different global virtualaddresses, depending on the value of the corresponding region registers.

An object (e.g., anonymous segment, mmaped file, system V shared memory,stack, etc.) that can be shared (read/written, depending on permissions)by multiple processes is a “shared object”. An object that can be sharedby multiple processes but is currently in use by only one process isstill a shared object.

An object that can be used only by one process is a “private object”. Aprivate object is created by the process for the purpose of using itonly within the context of the process.

An address space that is within the exclusive control of the process is“private address space”. This means that a process can expect thatanother process will not consume its private address space. Except forrare cases, a process can expect that its private address space is notaccessible to other processes.

An address space that is not entirely within the control of the processis a “shared address space”. The shared address space is global to theentire system. The shared address space may be visible to otherprocesses. Accessing the address in global address space is protected byusing protection keys (called protection IDs in the HP-PA architecture).

A private address space is tied to a particular process. A sharedaddress space is not tied to a particular process. The shared addressspace could be accessible to any process (4th quadrant in 32 bit addressspace) or to a subset (as is the case with memory windows).

In the current implementation of HP-UX, the private address spacecontains only private objects and the shared address space contains onlyshared objects. On the other hand, in an embodiment of the invention,the private address space can contain both private and shared objects,and the shared address space still can contain only shared objects.

Two different global virtual addresses that translate to the samephysical page are “aliases”. When a shared object is mapped in privateaddress space, it is typically shared using aliases. This is known as“aliasing”. In this, the object has many private mappings that aliasdifferent global virtual addresses to the same physical page(s) storingthe object's contents. This is the method used by multiple address space(MAS) operating systems to share data across processes. Under thisscheme, the virtual memory subsystem needs to add a translation to thephysical page for each process that needs to access the physical page.This has two consequences (contrast with the following scheme):

1. Sharing is at page granularity: This means that if process A maps theshared objects X and Y and process B maps the shared object Y only, thenonly the physical pages corresponding to object Y (and not X) have atranslation in the address space of process B.

2. Protection IDs are not required to prevent illegal access to data: Aprocess's ability to access a page is controlled solely by thetranslation —if the translation is present in its virtual space, theprocess can access the page as allowed by the translation (read/write);otherwise the process cannot access the page. On the HP-PA architecture,long pointer addressing is allowed. So, one protection ID is used forthe whole private address space.

When a shared object is mapped in the shared address space, the sharedobject can be shared by all processes using the same global virtualaddress. This is the method used in the current implementation of HP-UXto share data across processes. Since global virtual addresses arecomposed of the space (or region) ID and offset, this method of sharingimplies that both processes must typically have access to the same spaceID. Thus, in contrast to the method of sharing using aliasing, thisscheme differs based on the following:

(1) In this scheme the entire octant/quadrant of virtual addresses isshared. Thus, if processes A maps shared objects X and Y and process Bmaps shared object Y only, then process B will have object X residing inits virtual address space.

(2) The virtual memory subsystem typically therefore use protection IDsand access rights to prevent illegal accesses to data.

MPAS Process

A process that maps a shared object in a private address space is calledan “MPAS” (mostly private address space) process. Such a processperceives the same behavior as though the process is running on atypical MAS Operating System such as, for example, Solaris or Linux.Shared objects are mapped using aliasing. The process can map sharedobjects in a global address space for better performance using certainflags (e.g., MAP_GLOBAL, IPC_GLOBAL). This feature, using global addressspace for high-performance sharing, is not typically available for 32bit applications because of limited address space. The global addressspace is shown, for example, as segment 530 (RR5) in the 64 bit MPASaddress space layout (ASL) 500 in FIG. 5.

The name MPAS refers to the kind of address (shared vs. private) that isallocated to objects that this process wants to share. The name MGAS iscontrasted below.

MGAS Process

A process that maps a shared object in a shared address space is calledan “MGAS” (mostly global address space) process. Such a processperceives the same behavior as though the process is running on atypical SAS Operating System such as, for example, HP-UX. Shared objectsare mapped using a global address. Such a process may have part of itsvirtual address space consumed by other processes. If there is notenough space in the shared address space, then the kernel may map sharedobjects in private address space, as an optional implementation feature.

The name MGAS refers to the kind of address (shared vs. private) that isallocated to objects that this process wants to share.

Page Table

The page table is an important element of the VM (virtual memory)design. The page table stores all the translations that map a virtualaddress to a physical address. This page table is searched during a TLBmiss. If a translation is found in the page table, then the entry(translation) is inserted into the TLB. In other words, when atranslation that an application will use is not in the TLB, then thetranslation is searched in the page table and that translation is loadedas an entry from the page table into the TLB. If an entry is not foundin the page table, then a higher level virtual memory fault handler iscalled to resolve the translation fault. Some architectures, such asIA-64, have a hardware walker that searches the page table for betterperformance.

With a dual address space OS, the use of address aliasing will increase,since aliasing is used to share memory. Address aliasing places morepressure on the page table design. An embodiment of the inventionpermits the page table design to accommodate the following:

1. The page table should support a large number of aliases withoutsacrificing performance and efficiency.

2. The page table is preferably less complex, but extensible for futureenhancements.

Page Table Overview

All architectures today (e.g., PA-RISC, IA-64, etc.) use a virtualaddressing model. As shown in FIG. 3, the applications running on thesearchitectures access virtual addresses 305 that are mapped to a physicaladdress 310. These virtual addresses 305 need to be converted to aphysical address to locate the data. The mapping of the virtual addressto a physical address is referred to as a “translation”. This mappingfrom a virtual address to a physical address is provided by the pagetable. For better performance a subset of these translations are storedin the TLB (Translation Lookaside Buffer). The TLB is typicallyimplemented in the central processing unit (CPU) of the computer.

The page table is essentially a memory based table that contains thetranslations. The page table is primarily designed for efficientretrieval of translations using the virtual address as the key. Thereare several known techniques used to design the page table (see, e.g.,Jerry Huck, Jim Hays, “Architectural Support for Translation TableManagement in Large Address Space Machines”, in Proceedings of the20^(th) International Symposium on Computer Architecture, pages 39–50,ACM, which is hereby fully incorporated herein by reference). Every pagetable design attempts to optimize three different characteristics:

1. Minimize the time to service a TLB miss.

2. Minimize the physical memory space to maintain translations.

3. Maximize the flexibility for software to support a variety of VMmechanisms and capabilities.

There are three commonly used designs for the page table: (1)Forward-mapped page tables (these are sometimes referred to as amulti-level page table and are used in Solaris and Linux); (2) Invertedpage table (this is used in IBM AIX); and (3) the hashed page table(this is used in HP-UX).

Hashed Page Table

The hashed page table is very similar to the inverted page table. Itcombines the inverted page table and the hash table into a single hashedstructure, termed Hashed Page Table (HPT) 312. Each entry in the hashtable contains both the virtual address and the physical address. It isnoted that the hashed page table shown in FIG. 3 is just one exampletechnique that is used by the operating system 154 in order to map avirtual address to a physical address. Other suitable techniques may beused by the operating system 154 in order to perform the intendedfunctionalities.

The hashed page table 312 is indexed by some function 313 of the virtualaddress 305. The hash collision chain 314 is searched for the faultingaddress. If a match is found, then the TLB is directly loaded with theentry. If no match is found, a page fault is initiated that needs to behandled by virtual memory (VM).

Each page table entry (PTE) 315 typically contains the following fields:

(1) The virtual page number to which the entry maps.

(2) The physical page number to which the entry maps.

(3) A pointer 316 to the next entry in the hash collision chain.

(4) Flags such as valid, referenced, and modified.

(5) Protection and locking information.

Like the inverted page table, all the processes share this global table(hash page table 312). The addresses used by each process are unique.The address space identifier (ASID) of each process is included in thevirtual address 305. Virtual address isolation is achieved by usingprotection keys.

This implementation is used in HP-UX. On IA-64, the main hash table(without the collision entries) is concurrently used as a VHPT (VirtualHash Table). The VHPT, as defined by the IA-64 architecture, is anextension of the TLB hierarchy designed to enhance virtual addresstranslation performance. The IA-64 architecture is described further in,Intel IA64, “Intel IA-64 Architecture Software Developer's Manual”,Volume 2, which is hereby fully incorporated herein by reference. Theprocessor's VHPT walker can optionally be configured to search the VHPTfor a translation after a failed instruction or data TLB search. TheVHPT walker provides significant performance enhancements by reducingthe rate of flushing the processor's pipelines due to a TLB Miss fault,and by providing speculative translation fills concurrent to otherprocessor operations.

The main advantage of the hash table is that it is space efficient. Thesize of the page table is a linear function of the physical memory.Aliasing can be supported by adding the entries into the hashed pagetable 312. This creates multiple entries for the same physical page. Toomuch aliasing can reduce the effectiveness of the hashed page table dueto long collision chains. The hashed page table is ideal for operatingsystems, such as HP-UX, that use a single address space (SAS) model.

With the support of applications that use the MPAS model, the number ofaliases will increase significantly. This, in turn, will increase thenumber of collisions and impact overall system performance. To overcomethis problem, a hashed page table with LRU (least recently used)replacement is alternatively provided in an embodiment of the invention.

In this alternative, the above-mentioned hashed page table design isretained but the page table 312 is used as a cache of translations.Thus, the page table 312 does not contain all the translations butcontains the most frequently used translations. The MPAS processes willadd the alias entries into the hashed page table 312. To reduce thecollision chains due to many alias entries, an LRU (least recently used)algorithm can be used to replace entries in the collision chain 314. Nokernel translations will be replaced. User translations will be removedfrom the hash page table 312 by using some form of the LRU policy thatis executed by the page table management module 318.

Various alternatives can be used to implement the LRU policy. The LRUpolicy will prevent the collision chain 314 from growing too long. As anexample, in one LRU policy, the page table management module 318monitors the active and inactive translations by setting a bitassociated with a translation for each instance that the translation isused. The inactive or least recently used translations are periodicallyremoved or pruned by the page table management module 318.

The main advantages of a hash page table with LRU replacement include,for example, the following:

(1) An embodiment of the invention can retain all the advantages of thehashed page table.

(2) Improved performance.

(3) Page table performance is independent of the number of MPASprocesses.

(4) Less memory requirement for the page table.

Address Space Layout (ASL)

In this section, address space layouts (ASLs) are described forprocesses that will run under an architecture, in accordance with anembodiment of the invention.

A “private address space” is the portion of the process's address spacethat is under the process's control. This private address space couldinclude private objects, or objects shared with other processes by usingaliasing.

A “shared address space” is the portion of the process's address spacethat is not entirely under the process's control. This uses the samesemantics as the shared quadrants in HP-UX architecture and PA-RISCarchitecture.

FIG. 4A is a block diagram of an address space layout 400 for a 32 bitMPAS application (where the layout 400 is shown as segmentedrepresentation), in accordance with an embodiment of the invention. Inother words, the layout 400 is the segmented virtual address space for aprocess running as a 32 bit MPAS model. Segments 405 to 420 are in theprivate data space (where the private data space is an address spacethat is private to the process). Segment 425 is an unused area, andsegments 430 and 435 are in space that is not accessible by 32 bitpointers. Segment 440 is the address space of the kernel 162. Thesegments 425, 430, 435 and 440 are addresses that are not accessible bythe user.

The ASL 400 illustrates how a layout looks for a process that runs as a32 bit MPAS model. For example, the process may be an application thatis running in the MPAS model, and the application's layout will looklike the ASL 400 in FIG. 4A. The entire address space for a process thatruns as a 32 bit MPAS model is formed by private address spaces (i.e.,private address spaces 422 a, 422 b, 422 c, and 422 d).

FIG. 4B is a block diagram of an address space layout for a 32 bit MPASapplication (where the layout is shown as flat representation 450), inaccordance with an embodiment of the invention. Space 451 is the virtualaddress space allocated to process. Space 452 is the virtual addressspace not yet allocated to process. Space 453 is a “red zone” which doesnot permit user access.

All shared objects are mapped in the private address spaces in segments405, 410, 415, and 420.

In an embodiment, for the 32 bit MPAS process, the entire address spaceof the process is private address space. This means that all mmapedobjects (private and shared), and system virtual shared memory areallocated space from the same portion of the virtual address space. Themmap call allows the mapping of a shared file or private file. In otherwords, mmap is the Unix system call which establishes a mapping betweena range of addresses in a user process's address space and a portion ofsome “memory object” (typically a file, one of the special“devices”/dev/mem or /dev/kmem or some memory-mapped peripheral). Thisallows the process to access a file at random byte offsets without usingthe seek system call or to access physical addresses or kernel's virtualaddress space. In contrast, in an embodiment, for the MGAS processes,the shared objects are allocated from shared address space and privateobjects are allocated from private address space.

Since the entire space is private to the MPAS process, the entire spacecan use the same region ID (space ID). This region ID is not availableto any other process on the system. This means that the entire addressspace can use the public protection key. Special protection keys are notrequired to prevent another process from incorrectly using thetranslations for this process. In one embodiment, the sizes for thestacks are the same as those for MGAS processes.

The advantages of the above embodiment include the following:

1. Almost the entire address space is under the control of the process.The process can use its space for up to almost 4 Gs of private data, orshared data or any combination, etc.

2. Most frugal possible use of the address space: in other words, theuser fails to allocate a page of virtual memory only when all such pageshave been used up.

3. The embodiment is compatible with Solaris/Linux 32 bit ASL.

FIG. 5A is a block diagram of an address space layout 500 for a 64 bitMPAS application, in accordance with an embodiment of the invention.This address space layout is much larger than the address space for the32 bit MPAS as shown in FIG. 4A. Segments 505, 510, 515, 520, and 525are in the private data space. Segment 530 is a shared data space(global space), which include 64 bit shared addresses and shared text.The 64 bit shared addresses and shared text are addresses that areshared system-wide for all 64 bit processes. Segment 535 is reserved andis not accessible by the user. Segment 540 is the address space of thekernel 162. The segments 535 and 540 are addresses that are notaccessible by the user. The above embodiment permits the sharing of textwithout aliasing. This is more efficient than other approaches.

FIG. 5B is a block diagram of an address space layout for a 64 bit MPAS(shown as flat representation 550), in accordance with an embodiment ofthe invention. Space 551 is the virtual address space allocated toprocess. Space 552 is the virtual address space not yet allocated toprocess. Space 553 is a “red zone” which does not permit user access.

If a process maps a memory object (such as a memory mapped file, systemV shared memory, etc.) to a private address space, then the addressobtained from the mapping is from the private address space. Since theprivate address space is unique to each process, if a second process(which is of the same type as the first process) maps to the same memoryobject, then that second process will obtain another address in the sameprivate address space and both addresses will alias (point) to the samephysical page in the memory object.

If a process maps a memory object to a global address space and a secondprocess (which is of the same type as the first process) maps the samememory object, then the second process obtains the same address as theaddress of the first process. This leads to more efficiency in the useof hardware (i.e., CPU) resources.

In an embodiment, as a default setting, all shared objects are mappedinto the private address spaces in the segments 505, 510, 515, 520, and525 for the 64 bit MPAS ASL.

However, a flag can be set in the application program interface(s)(APIs) to override the above default setting so that the shared objectsfor a particular process is mapped in the global address space insegment 530.

FIG. 6A is a block diagram of an embodiment of the address space layout600 for a 32 bit MGAS process, in accordance with an embodiment of theinvention. Segment 605 is a shared text space. Segment 610 is a privatedata space. Segments 615 and 620 are shared data spaces. Segment 625 isan unused area, and segments 630 and 635 are not accessible by 32 bitpointers. Segment 640 is the address space of the kernel 162. The ASL600 illustrates how a layout looks for a process that runs as a 32 bitMGAS model. For example, the process may be an application that isrunning in the MGAS model, and the application's layout will look likethe ASL 600 in FIG. 6A. The entire address space for a process that runsas a 32 bit MGAS model is formed by the private data/private addressspace 602 and shared address spaces 603 a and 603 b. The shared objectsare stored in a shared data space in segment 615 or in segment 620.Every process can read the stored shared objects in the shared addressspaces.

The private objects are stored in the private data/private address spacein segment 610.

The shared objects and private objects are stored into the appropriatedata space by the kernel 162.

FIG. 6B is a block diagram of an address space layout for a 32 bit MGASapplication (where the layout is shown as flat representation 650), inaccordance with an embodiment of the invention. Space 601 is the virtualaddress space allocated to process. Space 602 is the virtual addressspace not yet allocated to process. Space 603 is a “red zone” which doesnot permit user access.

FIG. 7 is a block diagram of an embodiment of the address space layout700 for a 64 bit MGAS application, in accordance with an embodiment ofthe invention. Segments 705, 710 and 730 are shared data spaces. Segment715 is a shared text space. Segments 720 and 725 are private dataspaces. Segments 735 are not usable. Segment 740 is the address space ofthe kernel 162.

In an embodiment, as a default setting, all shared objects are mappedinto the private address spaces in the segments 720 and 725 for the 64bit MGAS ASL.

However, a flag can be set in the application program interface(s)(APIs) to override the above default setting so that the shared objectsfor a particular process is mapped in the global address space insegments 705 and 730. This flag is typically stored in the binary 1005(see FIG. 10) of the application and is read by the kernel 162. Thisway, the application can get the MPAS address space layout and thebenefits of sharing that some with a Single Address Space (SAS)operating system.

Address Space Allocation for Shared Objects

An embodiment of the invention allows for the creation of aliases toshared objects. This means that different processes could share the sameobject using different global virtual addresses. It may even be possiblefor a single process to access the same object using two differentvirtual addresses within its address space. Aliasing multiple addressesto a shared object is not allowed in the current implementation of theHP-UX product.

In an embodiment, an object can be shared by using aliases. However, ina preferred embodiment, an object is not allowed to have two differentvirtual addresses in shared space. Hence, in this embodiment, it isacceptable for an object to be addressable via multiple global virtualaddresses provided at most one of the global virtual addresses is inshared space. Also, the IA architecture recommends that aliasedaddresses be 1 MB aligned with each other.

The address space allocation function is performed by the operatingsystem 154 (FIG. 2).

FIG. 8 is a flowchart illustrating a method 800 of allocating addressspace for 32 bit MPAS processes, in accordance with an embodiment of theinvention. It is noted that the method in FIG. 8 is just one exampletechnique for achieving efficiency in the mapping operation. The method800 is an optional technique that can be used for efficient mapping ofmemory objects and is not intended to limit the scope of embodiments ofthe invention.

In a first case, a first process will map an object (step 805). Themethod 800 will choose a virtual address that allows efficient largepages (808) to be stored. Otherwise, the method 800 can choose (807) anysuitable virtual address for storing the object.

In a second case, one other process has mapped the object in virtualmemory (step 809). The method 800 will allocate the same virtual addressin this second process's address space that the other process has in itsaddress space. Otherwise, the method 800 will choose a virtual addresswhich is aligned with vaddr (which is the other process's virtualaddress for the object), such that large pages can be chosen (step 813).

Otherwise, the method 800 will choose a virtual address which is alignedwith vaddr, such that efficient aliasing can happen (step 814).

Otherwise, the method 800 will allocate any suitable virtual address(step 815).

In a third case, many other processes (or a plurality of processes) havemapped the object in virtual memory (step 817). The method 800 willchoose any suitable existing virtual address to align to (step 819).

FIG. 9 is a flowchart illustrating a method 900 of choosing the MGASmodel or the MPAS model by a software architect (application developer).As an example, the method 900 permits a software architect from oneparticular vendor (e.g., ORACLE CORPORATION) to write an application sothat the application will run in a computer from another vendor (e.g.,the HP-UX based architecture from HEWLETT-PACKARD COMPANY). As a result,the method 900 permits address space compatibility for applications. Instep (905) of method 900, the software architect determines if there isa need for an address space that is compatible with the MAS (multipleaddress) operating systems. Examples of an MAS operating system areSOLARIS, LINUX, and WINDOWS. If there is a need for an address spacethat is compatible with the MAS, then the software architect will choosethe MPAS model (step 907), and as a result, the application will see thelayout in FIG. 4A if the application is a 32 bit application or will seethe layout in FIG. 5A if the application is a 64 bit application. Ifthere is not a need for an address space that is compatible with theMAS, then the software architect determines if there is a need for moreefficient sharing between two or more processes, or more efficientsharing between a process and the file system (step 910). Efficientsharing between multiple processes, or between a process and a filesystem, leads to more speed in operation.

If there is a need for more efficient sharing between two or moreprocesses, then the software architect will choose the MGAS model (step915), and as a result, the application will see the layout in FIG. 6A ifthe application is a 32 bit application or will see the layout in FIG. 7if the application is a 64 bit application. If there is not a need formore efficient sharing between two or more processes, then the softwarearchitect determines if there is a need for more control over theaddress space (and operating system). For example, some applications mayrequire mapping of memory objects at particular addresses in order toprevent the failure of the process of the application. Some examples ofapplications that want to map objects at a fixed address are debuggersthat would like to map objects at the same address that is specified inthe coredump headers. Applications that need a fixed known address tomap a shared object will probably fail because the address may have beenused by another process.

If the software architect needs more control over the address space,then the software architect will choose the MPAS model in step (907). Onthe other hand, if the software architect does not need more controlover the address space, then the software architect can choose anyaddress space layout model in step (925). The method 900 then ends.

Recognizing an MPAS Binary

Since the system needs to execute both MPAS process and MGAS processconcurrently, there is a need for a method to identify at the time abinary is executed, as to whether a binary needs to be run as an MPASprocess or an MGAS process.

This method of determining whether the binary needs to run as an MPAS orMGAS process, is performed by the operating system 154 (FIG. 2).

Reference is now made to FIG. 10. In one example method, the softwarearchitect can set a notation in the binary 1005, which identifies thetype of address space layout (MPAS or MGAS) that the binary desires.This notation can be made in the binary 1005 using tools like thelinker, etc. The binary 1005 is included in an application 1010 thatwill be executed. The kernel 162 determine if the address space layoutwill be the MPAS model 150 (e.g., 32 bit MPAS model 155 or 64 bit MPASmodel 156) or the MGAS model 152 (e.g., 32 bit MGAS model 157 or 64 bitMGAS model 158) by reading the notation in the binary 1005. The kernel162 will partition the address space in memory, depending on which ofthe MPAS models 155 or 156 or MGAS models 157 or 158 is selected in thebinary 1005 notation. The kernel 162 can then map the objects for theapplication 1010 in the appropriate address spaces in memory, aspreviously discussed above.

The global address space model for shared memory is the most efficientdesign for the PA-RISC (precision architecture-RISC) architecturebecause the PA-RISC architecture uses a virtually indexed cache andplaces severe restrictions on the use of address aliasing. The PA-RISCchip is used in minicomputers and workstations from, for example,HEWLETT-PACKARD COMPANY, Palo Alto, Calif.

In a single address space (SAS) OS model, every process that is mappingthe same segment will receive the same address. In other words, theobjects that are being shared have the same address across all processin the system.

In the multiple address space (MAS) OS model, a process that is mappingthe same segment may have an address that is different from the addressof another process that is sharing the same segment. Aliasing is used topermit sharing of that segment.

A Single Address Space OS (SAS OS) has the following advantages whencompared to a Multiple Address Space OS (MAS OS):

1. The SAS OS permits a more efficient use of the Translation LookasideBuffer (TLB). A TLB is a table used in a virtual memory system and liststhe physical address associated with each virtual address. A sharedmemory page in a SAS OS will have only one entry in TLB for allprocesses sharing that page. A shared memory page in a MAS OS will haveone TLB entry per process that shares the page. Since TLB is a scarceresource, the SAS OS uses the TLB more efficiently.

2. The SAS OS is best suited for a virtual index cache. In an SAS OS,all processes use the same virtual address and thus all the processesshare the same cache line. In an MAS OS with virtually indexed cache,many cache lines will be used for the same memory location. In addition,there will be additional complexity needed in the cache controller toprovide coherency.

3. Large pages can be implemented efficiently by use of the SAS OS.Since all processes that share a memory segment use the same virtualaddress, every process will use the same large page. If aliasing is usedto share memory (as in the MAS OS), the addresses may not be aligned.This may add more than one translation for each large page.

4. By use of the SAS OS, the number of faults is independent of thenumber of processes that share the memory segment. If two processesshare the same page, the first process that faults will add thetranslation and the second process will use the same translation andavoid generating a fault. In an MAS OS, each process will incur a faultto add the translation.

A Single Address Space OS typically has the following disadvantages whencompared to a Multiple Address Space OS:

1. The amount of shared address space is limited for 32 bitapplications. On the HP-UX architecture from Hewlett-PackardCorporation, Palo Alto, Calif., the shared address space is limited to 2GB for all 32 bit applications in the system. This is inadequate todaywhen many systems have several Gigabytes of physical memory. Thisproblem can be solved by migrating the application to 64 bit but a largenumber of applications will remain as 32 bit due to the cost ofmigration.

2. The address space of each process is segmented. The HP-UXarchitecture has four segments. One segment each is used for text andprivate objects (data, stack, private mmf (mail message file) objects)and two segments for shared objects. Therefore, there is a waste ofaddress space in very sparsely populated segments.

3. Applications that want to map objects at a fixed address willprobably fail.

4. Same process mapping of an object more than once is not allowed.

5. There is a need for protection keys to prevent illegal accesses. If aprocess has many shared segments, then this could cause protection keythrashing since there are only 8 protection key registers.

In summary, a single address space OS (SAS OS), such as HP-UX, providesthe best performance compared to a multiple address space OS (MAS OS)but is less flexible.

The first three disadvantages of a single address space OS are describedin detail below:

Limited Shared Address Space—Processes that want to use shared memorywill be assigned the same unique address. All global addresses areallocated from a global pool. For 32 bit applications, the globaladdress space is limited to a maximum of 2 GB. This 2 GB limit is forthe whole system and not per process. As a result, the amount of sharedmemory available for a process depends on the amount used by otherprocesses in the system. For example, if a process uses 1 GB of sharedmemory, then another process cannot use more than 1 GB of shared space.In a Multiple Address Space OS, each 32 bit process can theoreticallyhave 4 GB of shared space. The 32 bit model is still the most popularprogramming model. Migrating to 64 bit is very expensive for manysoftware vendors and most do not have a need to migrate. Applicationsthat do not have virtual address pressure (on Solaris, Linux, etc.) haveno motivation to migrate their applications to a 64 bit model.

The limited address space on a SAS OS has been a severe restriction for32 bit applications. Various attempts have been made to alleviate thisproblem by implementing memory windows and SHMEM_GIC executables. Boththese solutions impose restrictions and require Independent SoftwareVendors to have an understanding of the address space layout. Forexample, in memory windows, if a process maps a shared memory segment inits window, another process that does not belong to the memory windowcannot share the same shared memory segment.

Segmented Address Space Layout—On the PA-RISC architecture, the virtualaddress space of the process is segmented into four quadrants of 1 GBeach for 32 bit processes and 4 exabytes each for 64 bit processes. Onequadrant is used for text, one quadrant for private data, and twoquadrants for shared memory. Because it is segmented, the boundaries arenot flexible. For a 32 bit application, 1 GB of the virtual addressspace is allocated for text even though the actual text size for theapplication is only a few kilobytes. This also limits the data to 1 GB.Again, attempts have been made in HP-UX to alleviate this problem byimplementing EXEC_MAGIC executables. Similarly, on Intel's Itaniumarchitecture, the virtual address space is segmented into 8 octants.This invention does not rely on the virtual address space beingsegmented. Embodiments of this invention could use segmentation toimplement it. In the description above, it is assumed that suchsegmentation is being used.

Embodiments of the invention permits an application developer to decidethe address space model to be supported by an operating system on acomputer and to overcome the above constraints of the address spacemodel.

The method of certain embodiments of the invention may typically beimplemented in hardware, software, firmware, or a combination thereof.In one embodiment, the method is executed by software or firmware thatis stored in a memory and that is executed by a suitable instructionexecution system. If implemented in hardware, as in an alternativeembodiment, the method can be implemented with any suitable technologythat is well known in the art.

The various engines or modules discussed herein may be, for example,software, commands, data files, programs, code, modules, instructions,or the like, and may also include suitable mechanisms.

Reference throughout this specification to “one embodiment”, “anembodiment”, or “a specific embodiment” means that a particular feature,structure, or characteristic described in connection with the embodimentis included in at least one embodiment of the present invention. Thus,the appearances of the phrases “in one embodiment”, “in an embodiment”,or “in a specific embodiment” in various places throughout thisspecification are not necessarily all referring to the same embodiment.Furthermore, the particular features, structures, or characteristics maybe combined in any suitable manner in one or more embodiments.

Other variations and modifications of the above-described embodimentsand methods are possible in light of the foregoing disclosure. Further,at least some of the components of an embodiment of the invention may beimplemented by using a programmed general purpose digital computer, byusing application specific integrated circuits, programmable logicdevices, or field programmable gate arrays, or by using a network ofinterconnected components and circuits. Connections may be wired,wireless, by modem, and the like.

It will also be appreciated that one or more of the elements depicted inthe drawings/figures can also be implemented in a more separated orintegrated manner, or even removed or rendered as inoperable in certaincases, as is useful in accordance with a particular application.

It is also within the scope of an embodiment of the present invention toimplement a program or code that can be stored in a machine-readablemedium to permit a computer to perform any of the methods describedabove.

Additionally, the signal arrows in the drawings/Figures are consideredas exemplary and are not limiting, unless otherwise specifically noted.Furthermore, the term “or” as used in this disclosure is generallyintended to mean “and/or” unless otherwise indicated. Combinations ofcomponents or steps will also be considered as being noted, whereterminology is foreseen as rendering the ability to separate or combineis unclear.

As used in the description herein and throughout the claims that follow,“a”, “an”, and “the” includes plural references unless the contextclearly dictates otherwise. Also, as used in the description herein andthroughout the claims that follow, the meaning of “in” includes “in” and“on” unless the context clearly dictates otherwise.

It is also noted that the various functions, variables, or otherparameters shown in the drawings and discussed in the text have beengiven particular names for purposes of identification. However, thefunction names, variable names, or other parameter names are onlyprovided as some possible examples to identify the functions, variables,or other parameters. Other function names, variable names, or parameternames may be used to identify the functions, variables, or parametersshown in the drawings and discussed in the text.

While the present invention has been described herein with reference toparticular embodiments thereof, a latitude of modification, variouschanges and substitutions are intended in the foregoing disclosures, andit will be appreciated that in some instances some features of theinvention will be employed without a corresponding use of other featureswithout departing from the scope and spirit of the invention as setforth. Therefore, many modifications may be made to adapt a particularsituation or material to the essential scope and spirit of the presentinvention. It is intended that the invention not be limited to theparticular embodiment disclosed as the best mode contemplated forcarrying out this invention, but that the invention will include allembodiments and equivalents falling within the scope of the appendedclaims.

1. A computer-implemented method to permit an application developer todecide the address space model to be supported by an operating system ona computer, the method comprising: selecting, by an operating system,one of a mostly private address space (MPAS) model and a mostly globaladdress space (MGAS) model, where if the MPAS model is selected, then aprocess is permitted to map a shared object in a mostly private addressspace (MPAS) layout so that the process perceives a behavior as if theprocess is running on a multiple address space operating system, andwhere if the MGAS model is selected, then the process is permitted tomap a shared object in a mostly global address space (MGAS) layout sothat the process perceives a behavior as if the process is running on asingle address space operating system.
 2. The computer-implementedmethod of claim 1, wherein the selected MPAS model or MGAS model isindicated in a binary in an application.
 3. The computer-implementedmethod of claim 2, wherein a kernel of the operating system reads thebinary to determine if support will be provided for the MPAS model orthe MGAS model.
 4. The computer-implemented method of claim 1, whereinthe MPAS layout comprises one of a 32 bit MPAS layout and a 64 bit MPASlayout.
 5. The computer-implemented method of claim 4, wherein the 32bit MPAS layout comprises private address spaces.
 6. Thecomputer-implemented method of claim 4, wherein the 64 bit MPAS layoutcomprises private address spaces and a shared address space.
 7. Thecomputer-implemented method of claim 1, wherein the MGAS layoutcomprises one of a 32 MGAS layout and a 64 bit MGAS layout.
 8. Thecomputer-implemented method of claim 7, wherein the 32 MGAS layoutcomprises shared address spaces and a private address space.
 9. Thecomputer-implemented method of claim 7, wherein the 64 bit MGAS layoutcomprises shared address spaces and private address spaces.
 10. Thecomputer-implemented method of claim 1, wherein the MPAS layout and theMGAS layout is partitioned in memory by a kernel of the operatingsystem.
 11. The computer-implemented method of claim 1, furthercomprising: managing a hash page table, where a least recently used(LRU) algorithm is used to remove inactive or least recently usedtranslations from the hash page table.
 12. The computer-implementedmethod of claim 1, further comprising: allocating a virtual addressspace for a 32 MPAS process by a method comprising: mapping, by aprocess, an object to a first virtual address that allows efficientlarge pages to be stored; and if the first virtual address is notavailable, then mapping the object to any virtual address.
 13. Thecomputer-implemented method of claim 1, further comprising: (a) if afirst process has mapped an object in virtual memory, then allocating asame virtual address in an address space of a second process, where thesame virtual address is in an address space of the first process; (b) ifstep (a) is not possible, then choosing a second virtual address that isaligned with (vaddr) which is the virtual address for the object for thefirst process; (c) if step (b) is not possible, then choosing a thirdvirtual address which is aligned with vaddr such that large pages can bechosen; (d) if step (c) is not possible, then choosing a fourth virtualaddress which is aligned with vaddr such that efficient aliasing ispermitted; and (e) if step (d) is not possible, then choosing anysuitable virtual address.
 14. The computer-implemented method of claim1, further comprising: if a plurality of processes have mapped an objectin virtual memory, then allocating any suitable existing virtual addressto align.
 15. A computer system to permit an application developer todecide the address space model to be supported by an operating system ona computer, the computer comprising: comprising: a processor; and anoperating system that can be executed by the processor, where theoperating system is configured to select one of a mostly private addressspace (MPAS) model and a mostly global address space (MGAS) model, whereif the MPAS model is selected, then a process is permitted to map ashared object in a mostly private address space (MPAS) layout so thatthe process perceives a behavior as if the process is running on amultiple address space operating system, and where if the MGAS model isselected, then the process is permitted to map a shared object in amostly global address space (MGAS) layout so that the process perceivesa behavior as if the process is running on a single address spaceoperating system.
 16. The apparatus of claim 15, wherein the selectedMPAS model or MGAS model is indicated in a binary in an application. 17.The apparatus of claim 16, wherein a kernel of the operating systemreads the binary to determine if support will be provided for the MPASmodel or the MGAS model.
 18. The apparatus of claim 15, wherein the MPASlayout comprises one of a 32 MPAS layout and a 64 bit MPAS layout. 19.The apparatus of claim 18, wherein the 32 MPAS layout comprises privateaddress spaces.
 20. The apparatus of claim 18, wherein the 64 bit MPASlayout comprises private address spaces and a shared address space. 21.The apparatus of claim 15, wherein the MGAS layout comprises one of a 32MGAS layout and a 64 bit MGAS layout.
 22. The apparatus of claim 21,wherein the 32 MGAS layout comprises shared address spaces and a privateaddress space.
 23. The apparatus of claim 21, wherein the 64 bit MGASlayout comprises shared address spaces and private address spaces. 24.The apparatus of claim 15, wherein the MPAS layout and the MGAS layoutis partitioned in memory by a kernel of the operating system.
 25. Anapparatus to permit an application developer to decide the address spacemodel to be supported by an operating system on a computer, theapparatus comprising: means for permitting a process to map a sharedobject in a mostly private address space (MPAS) layout so that theprocess perceives a behavior as if the process is running on a multipleaddress space operating system if a MPAS model, and for permitting theprocess to map a shared object in a mostly global address space (MGAS)layout so that the process perceives a behavior as if the process isrunning on a single address space operating system if a MGAS model isselected.
 26. An article of manufacture, comprising: a machine-readablemedium having stored thereon instructions to: permit a process to map ashared object in a mostly private address space (MPAS) layout so thatthe process perceives a behavior as if the process is running on amultiple address space operating system if a MPAS model, and to permitthe process to map a shared object in a mostly global address space(MGAS) layout so that the process perceives a behavior as if the processis running on a single address space operating system if a MGAS model isselected.